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Antriebssystem 



•■ .!l 
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CONTROI. 
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DIAGNOSIS 

Diagnoserechner- computer node 
Knoten 




Router od, 
ISDN/ analog 

ROUTER OR 
ISDN/ANALOGUE 




itetTn 



Diagnose 

DIAGNOSiS 



Femdiagnose 

REMOTE DIAGNOSIS 



(57) Abstract: The invention relates to a computer network for configuration, installation, monitoring, error-diagnosis and/or anal- 
ysis of several physical technical processes, in particular electrical drive processes, which occur under the control, regulation and/or 
monitoring of several process computer nodes, connected by means of at least one common communication system to at least one di- 
^5 agnosis computer node, in which one or several configuration, monitoring and diagnosis services and/or functions are implemented, 
fs| provided for the processes and/or the process computer nodes and/or the data processing processes running therein, whereby the 
common communication system is achieved by means of the Ethernet, or a similar asynchronous and/or bus or communication sys- 



tem worldng with a stochastic access method. 
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VeroffentUcht: 

— ohne ifaemationaien Recherchenbericht and emeut zu ver- 
qffentlichen nach Erhalt des Berichts 



Zur Erkldrung der Zweibuchstaben- Codes und der anderen Ab- 
kUrzungen wird auf die Erkldrungen ("Guidance Notes on Co- 
des and Abbreviations ") am Anfang Jeder reguldren Ausgabe der 
FCT-Gazette verwiesen. 



(57) Zusammenfassung: Rechner-Netzwerk zur Konfiguration, Inbetriebnahme, Obenvachung, Fehler-Diagnose und/oder -Ana- 
lyse mehrerer technisch-physikalischer Prozesse, insbesondere elektrischer Antriebsvorgange, die unter der Steuerung, Regelung 
und/oder Uberwachung durch mehrere Prozessrechnerknoten ablaufen, welche iiber wenigstens ein gemeinsames Kommunikations- 
system mit wenigstens einem Diagnoserechnerknoten verbunden sind, in dem ein oder mehrere Konfigurations-, Uberwachungs-, 
Diagnosedienste und/oder -funkdonen implementiert sind, die den Prozessen und/oder den Prozessrechnerknoten und/oder den daiin 
ablaufenden Datenverarbeitungsprozessen zugeordnet sind, wobei das gemeinsame Kommunikationssystem mit dem Ethernet oder 
einem sonstigen, asynchron und/oder mit einem stochastischen Zugri£fsver£ahren arbeitenden Bus- oder Konununikationssystem 
realisiert ist. 
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Rechnernetzwerk mit Diagnoserechnerknoten 

Die Erflndung betriffl ein Rechnernetzwerk zur Konfiguration. Inbetriebnahme, 
Oberwachung. Fehler-Diagnose und/oder -Analyse mehrerer technisch-physikalischer 

5 Prozesse. Solche kOnnen insbesondere elektrische AntriebsvorgSnge sein, die unter 
der Steuerung, Regelung und/oder Oberwachung durch mehrere 
Prozessrechnerknoten (im Belsplel eines elektrischen Antriebssystems: Antriebsregler) 
ablaufen. Die Prozessrechnerknoten sind Qber wenigstens ein gemeinsames 
Kommunikationssystem mit wenigstens einem Diagnoserechnerknoten verbunden. In 

10 letzterem sind ein oder mehrere Konfiguratlons-. Oberwachungs-, Dlagnosedienste 
Oder -funktionen impiementiert, die den Prozessen und/oder den 
Prozessrechnerknoten und/oder den darin ablaufenden Datenverarbeitungsprozessen 
zugeordnet sind. 

15 Femer betrifft die Erfindung einen Diagnoserechnerknoten fQr das genannte Netzwerk. 
Dieser ist als Server mit Schnittstellen fQr wenigstens eine Datenbank sowie zur 
Kommunikation mit wenigstens den Prozessrechnerknoten und mit sonstigen Client- 
Rechnerknoten ausgebildet. Weiter betrifft die Erfindung einen 
Kommunikationsrechnerknoten oder ein Kommunikationsmodul, letzteres als Software- 

20 und/oder Firmwaremodul ausgebildet, welche jeweils zum Einsatz in das genannte 
Netzwerk geeignet sind. 

Aus einem zusammenfassenden Taguhgsband zu dem im November 2001 in NQrnberg 
stattgefundenen KongreB „SPS IPC-Drives" 1st der Fachartikel „lnfo-Portal fUr 

25 anlagenObergreifende Prozessvisualisierung und -management via Internet" (Autoren: 
Andreas Kitzler und Werner Felten) bekannt. Darin wird eine Kommunikationsstruktur 
vorgeschiagen, bei welcher mehrere, voneinander unabhdngige 
Automatisierungssysteme, -zellen oder -aniagen Qber ein Informationsportal 
kombinierbar, QbenA/achbar, visualislerbar und dergleichen sind. Auf das 

30 Informationsportal idsst sich Qber das Internet zugreifen. Die Kommunikation zwischen 
den Automatisierungszeilen (sog. Supervisory Control And Data Acquisition - SCADA) 
einerseits und dem zentralen Webserver des Informationsportals andererseits erfolgt 



wo 2004/014022 




CT/EP2003/050349 



2 



Qber Standard-Schnittstellen auf der Basis der erweiterbaren Auszeichnungssprache 
XML. Dazu ist jedes Automatisierungssystem mit einem sogenannten XML-Agenten zur 
Kommunikation mit detn Informatlonsportal auf der Basis von TCP-IP versehen. So soil 
ein Management Qber das Web verschiedene Automatisierungszellen bzw. SCADA- 
Systeme qualifiziert auswerten kdnnen. Allerdings mOssen die einzelnen Sensordaten, 
bevor sle vom Informatlonsportal Qber das Web transportiert werden konnen. zunachst 
auf der fOr sie spezifischen Ebene gesammelt, dort aufbereitet und dem 
Informatlonsportal Qber die XML-Agenten zur VerfQgung gestellt werden. 

Aus DE 196 14 748 (A1-Offenlegungsschrift und C2-Patentsclirift) ist ein 
Fehlerdlagnosesystem bekannt, bei welchem ein Diagnoserechnerknoten Qber 
mehrere Bussysteme auch auf der Basis des Kommunikationsprotokoiis TCP/IP 
(Transport Control Protocol/Interface Program) mit Leitstandrechner. 
Steuerprozessrechner und Feldprozessrechnern kommuniziert. Zur Kommunikation 
zwisciien den Feldprozessrechnern einerseits und dem Dlagnosereclinerknoten 
andererselts wird ein serieller Feldbus nach dem Standard RS485 eingesetzt, wobei 
der Diagnoserechnerknoten den serielien Feldbus (RS485) entsprechend dem 
Master/Slave-Prinzip dominiert. Die Bandbreite fQr die DatenQbertragung (RS485 
Schnittstellen) reicht bei der zunehmenden . Datenflut nicht aus. Die auf der 
Bedienoberflache darzustellenden Infomnationen kdnnen aufgrund der Ring- 
Kommunikationsstruktur innerhalb eines Feldprozessrechner-Clusters nicht schnell 
genug Qbertragen werden. Die Abfrage eines Parameters dauert etwa 50 -60 ms - bei 
Aniagen mit ca. 500 Antrieben wurde z.B. ein anstehender Fehler erst nach mehr als 
einer Minute angezeigt werden. Jeder Parameter wird einzein Qbertragen. die 
Obertragung von Software-Paketen ist nicht mSglich. 

Ziei der vorliegenden Erfinder ist es, ein Hard- und insbesondere Softwarewerkzeug 
zur Diagnose komplexer technischer Aniagen und Systeme zu entwickeln. das auf die 
Anforderungen und BedQrfnisse der Benutzer zugeschnitten ist und vor allem 
folgenden Anforderungen genQgt: 

(1) Flexible Funktionen zur Obenwachung und Diagnose groBer Antrlebssysteme: 
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Ziel der Erfindung ist die Entwicklung eines Hard- und insbesondere 
Softwarewerkzeugs zur Oberwachung und Diagnose von insbesondere grolien 
Antriebssystemen. Das Diagnosesystem soil umfangreiche, flexible Funktionen bleten, 
die auf die z.T. sehr unterschiedlichen BedUrfnisse der verschiedenen 
Benutzergruppen beim Kunden zugesclnnitten sind. 

(2) EInfach zu bedienende, Qbersiciitliche Bedienoberflachen: 

Die Bedienoberflaclie des Diagnosesystems ist der einzige Teii der Software, mit der 
der Kunde in Kontakt kommt. Insofem ist sie das ^AushSngeschild" der Software und 
fQr deren Akzeptanz und Beurteilung von Seiten des Kunden entsclieidend. Beim 
Entwurf der Bedienoberflache ist darauf zu acliten, dass sie aucli fQr wenig geschultes 
Personal leiciit zu bedienen ist. Die Vielzaiil der bei der Diagnose von groSen Aniagen 
anzuzeigenden Informationen muR grapliisch aufbereltet werden und in einer 
eigonomischen Darstellung dem Anwender prasentiert werden. 

(3) VerkQrzung der zur Auffindung eines eventuellen Felilers notwendigen Zeit: 

Der Nutzen des Diagnosesystems soli fQr den Kunden darin liegen, dass er sofort nach 
dem Auftreten eines Felilers im Antriebsystem die fQr die Auffindung und Behebung 
des Fehlers notwendigen Informationen prasentiert bekommt. Hierdurdn kann die Zeit 
in der die Aniage nicht produktiv ist, reduziert werden. 

(4) Situationsabhangige Darstellung von Diagnose-lnformationen 

Das Diagnosesystem soil die richtige Infonnation zum riclitigen Zeitpunkt am richtlgen 
Ort zur VerfQgung stellen: 

• Aufbereitung der DIagnose-lnfomiation gemSft den Anforderungen des 
jeweiligen Benutzerkreises (z.B. Aniagenbediener, Techniker, 
Inbetriebnehmer) (-> die richtige Information) 

• Zeltnahe Anzeige von Diagnose-lnfonnationen direkt nach Auftreten eines 
Fehlers (-> zum richtigen Zeitpunkt) 

• Zugriff auf DAS DIAGNOSESYSTEM von beliebigen PCs des Kunden ohne 
Installationsaulwand - sowohi Im lokalen Kundennetz als auch ober 
Femzugriff. (-> am richtigen Ort) 
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(5) Reduzierung von kritischen Aniagenzustanden durch vorbeugende Wartung und 
standige Oberwachung der Aniage: 

ZukOnftig soil das Diagnosesystem Mechanismen beinhalten, die dazu beitragen, 
5 eventuell bevorstehende Ausfaile yon Geraten vorab zu erkennen und dem Kunden 
mitzuteilen. So kann die ZuverlSssigkeit des Antriebsystems weiter erh6lit werden. 

(6) Umfassende Diagnose- / Messfunktionen via sciineller Etfiernet-Sclinittstelle unter 
Einbeziehung des Ethernet-Gesamtkonzeptes der Masclnine urn z.B. ein 

10 Referenzsignal einer realen Leitachse zu messen, aufeuzeichnen und auszuwerten 

(7) Vorbeugende Diagnose (z.B. Geberausfall in ... Tagen walirscheiniicri) 

(8) Ein .Expertensystem" soli Fehlerlokalislerung Innerhalb max. 10 min sicherstellen 
15 und Fehlerbeliebung wesentlich vereinfachen 

(9) Webbrowser-Funktlonen 

(10) Das Diagnosesystem muss auf mehreren Plattfomien laufen kOnnen (z.B. diverse 
20 Leitstande) 

(11) Integrierte Datenprotokollierung / -analyse (Registenwerte, Kommandos) muss 
ohne zusatzliclie Hardware (Datenanalyzer) verfugbar sein 

25 (12) Zykliscl-ie Datenprotokollierung auf zentralen Datenbankserver 

(13) Zugriffsmoglichkeit fiir den IVIasclninenhersteller auf ausgelieferte Antriebssysteme 
per Femdiagnose 



30 (14) BedienerfUlirung und Parameterhandling (Konfiguration, Inbetriebnafime, 
Fehlersuclie, Software-Updates) sind wesentlich zu verbessem 
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(1 6) Entwicklung von branchenQbergreifenden Ldsungen 

Trotz BerQcksichtigung der Kundenwtinsche soil das DIagnosesystem fDr den 
branchenQbergreifenden Einsatz entwickelt werden. so dass ein EInsatz in anderen 
Branchen (z.B. Werkzeugmaschinen, Textilmaschinen) ohne groBen Aufwand mOglich 
ist 

(16) Bereitstellung der Softwarewerkzeuge fOr die Inbetriebnahme von 
Antrlebssystemen mit zukonflig bis zu 500 Achsen 

Antriebssysteme mit mehr als 300 Achsen sind ohne SoflwareuntersttJtzung nur noch 
mit unverhaitnismaUig hohem Aufwand in Betrieb zu nehmen. HierfOr soli mit dem 
DIagnosesystem ein geeignetes Softwarewerkzeug entwickelt werden. 

(17) VerkOrzung der Inbetriebnahmezeit und Reduzierung der Inbetriebnahmekosten: 
Mit Hilfe des Diagnosesystems sollen die Kosten fOr die Inbetriebnahme durch, die 
Bereitstellung geeigneter softwaregestiltzter Verfahren langfrisOg reduzlert werden. 

(18) Weltweiter Zugriff auf den oder die technisch-physikalischen Prozesse der Aniage, 
insbesondere Antriebssystem. zur schnellen und kostengOnstlgen Diagnose: 

Fur einen schnellen und zuveriassigen Service und zur Aniagendiagnose soil ein 
weltweiter Zugriff auf das Antriebssystem mSglich sein. 

Dem gegenuber wird zur Vermeidung sich aus dem Stand der Technik ergebender 
Nachteile bei dem Rechner-Netzwerk mit den eingangs genannten Merkmalen 
erfindungsgemali vorgeschlagen, dass das gemeinsame Kommunikationssystem 
zwischen dem Prozessrechnerknoten und dem Diagnoserechnerknoten mit dem 
Ethernet oder einem sonstigen, asynchron und/oder mit einem stochastischen 
Zugriffsverfahren arbeitenden Bus- Oder Kommunikationssystem realisiert wird. Ein 
derartiges Zugriffsverfahren Ist beispielsweise unter der AbkOrzung „CSMA/CD" 
(Carrier Sense Multiple Access/with Collision Detection) bekannt. Dieser industrielle 
Ethernet-Einsatz zur Realisierung einer Kommunikations-lnfrastruktur erniSglicht im 
Vergleich zur vortekannten Kommunikation Ober RS485 und dem zugehSrigen USS- 
Protokoll eine hShere Bandbreite fOr die DatenObertragung. so dass grOliere 
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Datenmengen von dem ProzeUrechnerknoten zum Diagnoserechnerknoten Qbermittelt 
werden konnen. HierfOr besteht aufgrund der zunehmenden Komplexitat der 
technischen Aniagen mit wachsender Anzahl von Prozessrechnerknoten und 
zugehCrigen technisch-physikalischen Prozessen ein zunehmendes BedOrfnis. 

5 Weiterhin hat sich das Ethernet im BQrobereich als weitgehender Standard fOr die 
Obertragung groRer Datenmengen durchgesetzt. Durch die erfindungsgemaUe 
VenA^endung von Ethernet mit dem ebenfalls an sich bekannten Protokoll TCP/IP ist for 
das erfindungsgemaiJe Diagnosesystem der Weg zur Kompatibilitat und/oder 
Verbindung mit dem Internet geebnet. Damit wird der Vorteil erzielt. dass 

10 Diagnosedaten Qber das Internet verschickt werden kOnnen. Zudem kann eine 
technische Aniage mit einer VIelzahl von Prozessen von einem beliebigen Client- 
Knoten aus insbesondere Qber das Internet Qbenwacht werden. 

Um die umfangreich anfallenden Datenmengen sinnvoll verarbeiten zu konnen. ist eine 
15 dezentrale Diagnose nebst Vorverarbeitung zweckmaHig, Ebenfalls sinnvoll 1st es, 
umfangreiche Diagnosefunktlonen mOglichst nahe an den betroffenen, technisch- 
physikalischen Prozess oder Gerat anzusiedeln. In dieser Hinsicht ist nach einer 
vorteilhaften Erfindungsausbildung dem Ethernet oder dem sonstigen Bus- oder 
Kommunikationssystem und wenigstens einem der Prozessrechnerknoten ein 
20 Kommunikationsmodul oder -rechnerknoten zwischengeschaltet, das bzw. der den 
jeweiligen Prozessrechnerknoten an das Internet oder sonstige Bus- oder 
Kommunikationssystem anbindet. Der Kommunikationsrechnerknoten oder das 
Kommunikationsmodul kann zusatzlich auch noch die ereignis- und/oder 
anfragebasierte Kommunikation zum Diagnoserechnerknoten Ubernehmen. 

25 

Insbesondere wenn in weiterer Ausgestaltung der Erfindung das Kommunikationsmodul 
Oder der Kommunikationsrechnerknoten so ausgebildet ist, dass es bzw. er Qber XML- 
Protokolle und/oder als XML-basierte Schnittstelle mit dem Diagnoserechnerknoten 
kommuniziert (XML: Extensible Markup Language), kann bei der Projektierung und 
30 Konfiguration der damit zu Qberwachenden, technischen Aniage sehr flexibel und mit 
verhaitnismaBIg gerlngem AulWand auf technische Anforderungen und 
KundenwQnsche reagiert werden. Auf der Basis der Erfindung ia(it sich eine 
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standardisierte, flexible Netzwerk-Rechnerstaiktur schaffen, die leicht um weitere 
Funktionen erweitert werden kann. Vor allem lassen sich mit dam Einsatz der XML- 
Protokolle und/oder der XML-basierten Schnittstellen die Diagnosedaten aus dem 
Prozessrecliner- und/oder Kommunikationsknoten fur den Diagnoserechnerknoten 
5 bereits so aufbereiten, dass diese vom Diagnoserechnerknoten leicht Qber das Internet 
an Client-Rechnerknoten Qbertragen werden kdnnen. 

Um die umfangreichen Datenmengen Qber eine dezentrale Vorverarbeitung sinnvoll 
bewaitigen zu kCnnen, ist nach einer Ausbildung der Erflndung vorgesehen, dass das 
10 Kommunikationsmodul oder der Kommunlkationsrechnerknoten mit Funktionalitaten zur 
Fehlersuche oder Diagnose Im Bereich wenigstens eines der Prozessrechnerknoten 
Oder eInes technisch-physikalischen Prozesses versehen Ist. Mit diesem Konzept 
lassen sich umfehgrelche Dlagnosefunktionen nahe an den betroffenen Komponenten 
ansiedeln. 

13 

Der Internet-Kompatlbllltat des erfindungsgemSSen Diagnosesystems dient es. wenn 
nach einer Erfindungsausbildung der Diagnoserechnerknoten zur Bereitstellung oder 
wenigstens UnterstOtzung webbasierter BedienoberflSchen fOr Cllent-Rechnerknoten 
ausgebildet ist. Dies kann Qber DatenfemQbertragung und/oder ein Weitverkehrsnetz 
20 (z. B. Internet) erfolgen. Ferner liegt es im Rahmen der Erfindung, wenn dazu der 
Diagnoserechnerknoten mit Funktionskomponenten versehen ist, welche die Bildung 
der Bedienoberfiachen in den Client-Rechnerknoten unterstGtzen. 

Problematisch ist. ob der Benutzer an einem Client-Rechnerknoten sich slcher sein 
25 darf, dass die Client-Benutzeroberflache (Diagnose-) Daten und -Infomnationen 
wiedergibt, die noch weitgehend aktuell bzw. zeitnah sind. Ein etwaiger Ausfall des 
Diagnoseservers soli erkennbar seIn, und ferner sollen Fehler und sonstige Ereignisse 
Im technisch-physikalischen Prozess und/oder Prozessrechnerknoten zeitnah dem 
Benutzer Ober die Bedienoberfiache des ihm zugeordneten Cllent-Rechnerknotens 
30 ml^eteilt werden kdnnen. 
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Zur LOsung dieser Problematik wird im Rahmen der allgemeinen erfinderischen Idee 
ein zum Einsatz als Server In das soeben skizzierte Netzwerk ausgebildeter 
Diagnoserechnerknoten mit folgenden Merkmalen vorgeschlagen: 

■ der Diagnoserechnerknoten ist zur Arbeit als Server elngerichtet und besitzt 
Schnittstellen zu wenigstens einer Datenbank. zur Kommunikation mit den 
Kommunikatlons- und/oder Prozessreclinerknoten und zur Kommunikation mit 
sonstigen Cllent-Recinnerknoten; 

■ die eine oder mehreren Schnittstellen zu den sonstigen Cllent-Rechnerknoten 
sind unter VenA/endung eines (an sich bekannten) Servlet-Containers 
realisiert, welcher der Obertragung von Diagnosedaten an die Cllentknoten 
dlent; 

■ diese Diagnosedaten sind aus den Schnittstellen erhaltlich, die der 
Kommunikation mit dem Kommunikations- und/oder Prozessrechnerknoten 
dienen; 

■ die eine oder mehreren genannten Schnittstellen, welche den 
Kommunikations- und/oder Prozessrechnerknoten zugeordnet sind, sind auf 
der Basis des Ethernet realisiert; 

■ es ist ein Diagnosekanal gebildet, der eine oder mehrere Ethernet- 
Schnittstellen umfasst, die den Kommunikations- und/oder 
Prozessrechnerknoten zugeordnet sind; 

■ der Diagnosekanal umfasst femer ein Ereignis-Managementmodul, das auf 
die Datenbank zugreifen sowie an den Ethernet-Schnittstellen erhaltene 
Diagnosedaten verarbeiten kann; 

■ femer umfasst der Diagnosekanal ein Ereignis-Oberwachungsmodul, das auf 
der Basis des Servlet-Containers gebildet ist und Ausgangsdaten aus dem 



wo 2004/014022 




^CT/EP2003/050349 



Ereignis-Managementmodul einem oder mehreren Applets auf externen 
Client-Rechnerknoten zur VerfUgung stellt. 

Damit ist es mdglich, Daten, insbesondere Diagnosedaten, zwischen dem 
5 Diagnoserechnerknoten und der Benutzeroberflache eines Client-Rechnerknotens 
zyklisch Qbertragen zu kOnnen. So kann ein Benutzer am Client-Rechnerknoten 
zeitnah Qber im Bereich der Prozessrechnerknoten und/oder der technisch- 
physikalisohen Prozesse auftretende Ereignisse informiert werden. Dem Benutzer 
kOnnen in vielfaltiger und komfortabler Weise so Anlageinformationen auf der 
10 Benutzeroberflache des Client-Rechnerknotens zur VerfUgung gestellt werden. Die 
DatenObertragung lasst sich besonders vorteilhaft mit Java-Technologien realisieren, 
namlich einem Java-Servlet auf dem Diagnoserechnerknoten als Server und einem 
Java-Applet beim Client-Rechnerknoten. So ist es auch m6glich, einen Benutzer am 
Client-Rechnerknoten Diagnoseinformationen In Form von Webseiten zur VerfOgung 
15 zu stellen. Dabei bietet der Einsatz von Java-Applets sehr flexible 
DarstellungsmOglichkeiten, die durch den Zukauf von Applets mit grafischen 
Fahigkeiten leicht enweiterbar sind. 

Der Losung der obigen Problematik dient der erfindungsgemSRe Diagnosekanal im 
20 Diagnoseserver, mittels welchem eine zyklische Kommunikation reallslert werden kann, 
wobel regelmaBig Datenpakete ausgetauscht werden. Fehit ein Datenpaket, kann im 
Client-Rechnerknoten erkannt werden, dass ein Fehlerfall aufgetreten ist („Event + 
Heartbeat"). Der Heartbeat bzw. Herzschlag entspricht gleichsam der vor allem in der 
Eisenbahn-Sicherheitstechnik bekannten Totmannstaste. Mittels des Diagnosekanals 
25 lasst sich also eine Anzeige von vom Prozessrechnerknoten herruhrenden 
Diagnosedaten Qber den Diagnoseserver bzw. Diagnoserechnerknoten zum Client- 
Rechnerknoten auf dessen Bedienoberfiache gleichsam triggern. Die Darstellung des 
Fehlerfalls auf der Benutzeroberflache ist aufgrund des erfindungsgemafien 
Diagnosekanals nicht mehr davon abhSngig, dass vom Client-Rechnerknoten eine 
30 Anfrage zum Diagnoseserver Qbermittelt wird. Vielmehr kSnnen die 
Prozessrechnerknoten, gegebenenfalls Qber jeweils eigens zugeordnete 
Kommunikationsknoten, gleichsam selbst die Darstellung neuer Ereignisse, 
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insbesondere Fehler, indizieren. Dieser Mechanismus wird wesentlich durch den 
Diagnosekanal im Diagnoserechnerknoten unterstotzt, indem Ober das Ereignis- 
Oberwachungsmodul vom Prozessrechnerknoten mitgeteilte Diagnose- bzw. 
Fehlerdaten an die Bedienoberflache des Client-Rechnerknotens fur einen dortlgen 
5 Benutzer weitergeleitet werden. 

GemdB einer besonderen Ausbildung slnd die Schnittstellen im 
Diagnoserechnerknoten fQr Kommunikation mit den Kommunikations- und/oder 
Prozessrechnerknoten mittels XML-Protokolle bewerkstelligt. Dadurch lassen sich in 
10 der Flexibilitat eingeschrSnkte, proprletare LOsungen vennelden. 

Im Diagnoserechnerknoten sollen alle Diagnoseinfonnatlonen den 
Benutzeroberfiachen auf den Client-Rechnerknoten webbasiert zur VerfOgung gestellt 
werden. Als besonders zweckmaiiig dafQr stellte sich eine Kombination des 
15 Webservers Appache mit der Servlet-Engine „Tomcat" heraus. 

Bei dem oben angegebenen, erfindungsgemaBen Diagnoserechnerknoten sorgt der 
Diagnosekanal dafOr. im Ereignis-, insbesondere Fehlerfall den Client-Rechnerknoten 
darauf mit seiner Benutzeroberfiache zur Reaktion zu bringen. Tritt ein Fehler oder ein 

20 Ereignis auf, werden entsprechende Diagnosedaten an der Ethernet-Schnlttstelle des 
Diagnosekanals erfasst, welche den Kommunikationsmodulen, Kommunikations- 
und/oder Prozessrechnerknoten zugeordnet slnd. Auf die Diagnose- bzw. 
Ereignisdaten in Fomn beispielsweise eines Telegramms an der Ethernet-Schnittstelle 
kann das Erelgnis-Managementmodul zugreifen. Die Ereignis- bzw. Diagnosedaten 

25 werden verarbeitet und eine entsprechende Information in die Datenbank geschrieben. 
Die Ausgangsdaten aus dem Ereignis-Managementmodul gelangen zu dem im Servlet- 
Container angelegten Ereignis-Oberwachungsmodul. Dieser tibermittelt an seinem 
Ausgang eine Information im Beispielsfall des Intranets zweckmaRig direkt, ohne 
Zwischenschaltung eines Webservers, an einen Client-Rechnerknoten. Die Information 

30 beinhaltet eine Aufforderung, beim Diagnoseserver wegen Ereignisse oder Fehler 
reprasentierende Diagnosedaten nachzufiragen. Damit wird die Notwendigkeit eines 
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standigen, den gesamten Betrieb Qber andauemden Pollings, was erhOhte 
DatenUbertragungskapazltaten erfordem wQrde, vernnieden. 

Zur Anbindung der Prozessrechnerknoten an das Ethernet oder ein sonstlges, 
asynchron arbeitendes Kommunikationssystem mit dem Diagnoserechnerknoten, und 
insbesondere zur Schaffung der Mflglichkeit einer ereignisbasierten Kommunikation 
zwischen Prozessrechnerknoten und Diagnoserechnerknoten, wobel umfangrelche 
DIagnosefunktlonen naOglichst nahe zum technisch-physikalischen Prozess verlagert 
werden, wird Im Rahmen der allgemeinen erfinderlschen Idee ein 
Kommunikationsrechnerknoten Oder ein Kommunikationsmodul als Software- und/oder 
Firmwaremodul vorgeschlagen, der zur Verwendung im oben skizzierten Rechner- 
Netzwerk geeignet ist und sich durch fblgende iVIerkmale auszeichnet: 

■ der Kommunikationsrechnerknoten oder das Kommunikationsmodul weisen 
eine erste Schnittstelle auf, die dem wenigstens einen 
Diagnoserechnerknoten zugeordnet ist; 

■ diese Schnittstelle Ist zur Kommunikation Qber Protokolle der TCP/I P-Familie, 
einschllelillch UDP/IP, vonzugsweise auf der Basis des Ethernet programmiert 
Oder ausgebildet; 

■ der Kommunikationsrechnerknoten bzw. das Kommunikationsmodul weisen 
eine oder mehrere zweite Schnittstellen auf, die einem Oder mehreren der 
Prozessrechnerknoten zugeordnet sind, 

■ die erste und die eine oder mehreren zweiten Schnittstellen sind miteinander 
Qber einen oder mehrere Infomnationsbroker koppelbar; 

■ der eine oder die mehreren Infomiationsbroker sind jeweils programm- 
und/oder schaltungstechnisch als Submodule fQr bidirektionale, anfrage- 
und/oder ereignisbasierte Datenkommunikation eingerichtet, die zwischen der 
ersten und der einen oder den mehreren zweiten Schnittstellen stattfindet. 
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Zweck des Kommunikationsmoduls bzw. Kommunikationsrechnerknotens ist es. 
samtliche Kommunikationsaufgaben zwischen dem Prozessrechnerknoten und dessen 
AuBenwelt abzuwickeln. Hierzu gehort z. B. der Zugriff auf Parameter des 
Prozessrechnerknotens, beispielsweise Antriebsreglers, der Down- und Upload von 
beispielsweise Regler-Firmware und zugehflriger DatensStze, sowie die Bereitstellung 
von Diagnosefunktronalitdten. 

Im Hinblick auf die Reallsierung der Hardware des erfindungsgemaSen 
Kommunikationsknotens kdnnte es zweckmSBig sein, eine eigenstandlge Baueinheit 
mit darin Integrierten Kommunikationsfunktionen zu fertigen und auf die Platine fDr den 
Prozessrechnerknoten aufeustecken. Alternativ kann die Kommunikationsknoten- 
Hardware ganz oder teilweise in die Sclialtung auf der Platine des 
Prozessrechnerknotens und/oder der des Diagnoserechnerknotens integriert sein. 
Alternativ liegt es auch im Rahmen der Erfindung, den Kommunikationsknoten 
gleichsam als „PC" mit einem eigenen Gehause auszufQhren. das auf eine 
Schienenhalterung fOr den Prozessrechnerknoten mit aufgeschnappt werden kann. 

Als Betriebssystem for den erfindungsgemaSen Kommunikationsknoten 
(Kommunikationsmodul oder Kommunikationsrechnerknoten) hat sich der EInsatz von 
Linux als zweckmaBig erwiesen, was Lizenzkosten fOr die Entwicklungsumgebung 
entfallen lasst. Zudem ist C** als ausreichend flexible und mSchtige 
Programmiersprache geeignet. 

Mit der erfindungsgemaBen Konzeption des Kommunikationsknotens zwischen 
Prozessrechner und Diagnoserechner erglbt sich die Moglichkeit fur die Obertragung 
der Daten an die AuBenwelt Qber XML-basierte Protokolle (anstelle von proprietaren 
Protokollen). Mit der an sich bekannten und weit verbreiteten Auszeichnungssprache 
XML fOr Intemetanwendungen in Verbindung mit der Bereitstellung 
plattfonnunabhangiger XML-Parser ergibt sich ferner die Mdglichkeit, auch in 
heterogenen Systemumgebungen einfach Daten auszutauschen. Durch bereits 
vorhandene Validierungsmechanismen (XML-Schema) kOnnen die Struktur und der 
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zulassige Inhalt eines Telegramms einfach festgelegt werden. wobei die PrQfung auf 
GQitigkeit automatlsch erfolgt. Als zeichenorientiertes Protokoll ist ein XML-basiertes 
Telegramm einfach zu erzeugen und notfalls auch von Hand Oder von einfachen 
Skripten zu bearbeiten. 

Um mOglichst umfangreiche Diagnosefunktionen mOglichst nahe am technisch- 
physikalisohen Prozess implementieren zu kOnnen, wird gemaiS einer vorteilhaften 
Erfindungsausbildung vorgeschlagen, dass der eine Oder die mehreren 
Informationsbroker Funktionskomponenten umfassen, die zur Fehlersuche oder 
Diagnose im Berelch der Prozessrechnerknoten und/oder technisch-physikalisclien 
Prozesse ausgebildet sind. Vor allem in diesem Zusammenhang ist die weitere 
Erfindungsausbildung vorteilhaft, auf dem Kommunikationsreciinerknoten oder -modul 
einen Interpreter for die AblauffShigkeit von an sicli bekannten Skripten einzurichten, 
die zum Zugriff auf Funktionselemente beziehungsweise Funktionalitaten in dem oder 
den Infonnationsbrokern zwecks AusfQhmng von Oberwachungs- und 
Diagnosefunktionen ausgebildet sind. Ein damit erzielbarer Vorteil besteht in der 
effektiveren Fehlersuche: Mittels der Skripten in Verbindung mit der Sprache Perl 
lassen sich in relativ einfacher Weise effiziente Fehlersuchbedingungen einrichten 
bzw. vom Diagnoserechnerknoten auf dem Kommunikationsknoten laden. Damit lasst 
sich die Funktionalitat. die auf dem Kommunikationsknoten zur VerfOgung steht, noch 
einmal erweitem. 

Es liegt im Rahmen der Erfindung, dass das Kommunikationsmodul oder der 
Kommunikationsrechnerknoten in bestimmten Fallen dann als Server gegenuber dem 
Diagnoserechnerknoten (als Client) arbeitet, wenn seitens des 
Diagnoserechnerknotens Anforderungen an Informationsdienste vorliegen, die 
beispielsweise von Informationsbrokern im Kommunikationsknoten auszufuhren sind. 

Weitere EInzelheiten, Merkmale, Vorteile und Wirkungen auf der Basis der Erfindung 
ergeben sich aus der nachfolgenden Beschreibung bevorzugter beispielhafler 
AusfDhrungsfomnen der Erfindung und aus den Zeichnungen. Diese zeigen in: 
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Figur 1 ein schematisches Gerateschaubild des 
erfindungsgemaiSen Diagnosesystems mit lokalem und weltweitem 
Zugriff auf Diagnoseinfornnationen; 

5 Figur 2 eine schematische Block-Darstellung eines 

beispielhaften Kommunikationssystems eines mit dem 
erfindungsgemaiSen Dlagnosesystem versehenen. elektrisclnen 
Antriebssystems; 

0 Figur 3 in schematisclier Blockdarstellung die Grobstruktur 

des erfindungsgemaBen Diagnosesystems; 

Figur 4 eine detaillierte Blockbild-Darstellung der Internen 
Struktur des Diagnose-Reclinerknotens; 

15 

Figur 5 eine gleichartige Blockdarstellung der internen 
Struktur des Kommunikations-Rechnerknotens; 

Figur 6 eine beispielhafte Bedienoberfiache auf einem Client- 
20 Rechnerknoten fQr ein anlagenorientiertes Aniagenbild am Belsplel 

einer Druckmaschine, erzeugt mittels eines Java-Applets in 
Verbindung mit einem korrespondierenden Servlet auf dem 
Diagnoserechnerknoten; 

25 Figur? eine weitere, gleichartig erzeugte Bedienoberfiache 

uber ein antriebssystem-orientiertes Aniagenbild am Beispiel einer 
Druckmaschine. 

Gemafi Figur 1 ist ein elektrisches Antriebssystem fQr eine Vielzahl von zueinander 
30 synchron anzutreibenden Achsen 1 beispielsweise einer Druckmaschine mit einer 
Vielzahl von Elektromotoren 2 versehen. die jeweils eine Achse 1 antreiben. Die 
Elektromotoren 2 werden jeweils Qber Wechselrichter 3 mit vorgeschalteten 
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Prozessrechnerknoten 4, im vorliegenden Druckmaschinen-Antriebssystem als 
Antrlebsregler ausgefuhrt, angesteuert bzw. geregeit. Zur Kommunikation mit einem 
Dlagnoserechner-Knoten sind den Prozessrechnerknoten jeweilige 
Kommunikationsrechnerknoten 5 vorgeschaltet. Der Wechselrichter 3, der 
5 Prozessrechnerknoten 4 und der Kommunikationsrechnerknoten 5 kannen baulich auf 
einer gemeinsamen Baugruppe, wie zeichnerisch dargestellt, integriert sein, welche in 
einenn jeweiligen Schaltschrank 6 untergebracht ist. 

GemSR Figur 1 kann der Diagnoserechnerknoten auch mit einem Leitstand, mehreren 
10 Client-Rechnerknoten fQr Diagnose und Qber einen Internet-Router Oder ISDN Oder 
analog Qber das Internet mit einem oder mehreren. ortlich entfernten Cllent- 
Rechnerknoten zur Ferndiagnose kommunizleren. Damit sind die am jeweiligen 
Antriebsprozess der Elektromotoren 2 mittels des Prozessrechnerknotens 4 und/oder 
des Kommunikationas-Rechnerknotens 5 aufbereiteten Diagnosedaten Qber den 
15 Diagnoserechnerknoten sowohl lokal als auch von einem belieblgen Ort aus abrufbar. 

GemaB Figur 2 sind die einzelnen Prozessrechnerknoten 4 im Rahmen einer 
Ringstruktur zur synchronisierten Kommunikation miteinander verbunden, wobei stets 
einer der Prozessrechnerknoten 4 (in Figur 2 der jeweils dunkler unterlegte) als 
20 Kommunikationsmaster arbeltet. Dieser besitzt gleichzeitig eine Schnlttetelle zur 
asynchronen Kommunikation Qber das Ethernet mit mehreren 
Steuerungsrechnerknoten SPS. Urn auch eine Querkommunikation zwischen einzelnen 
Ringen mit Prozessrechnerknoten 4 zu unterstutzen, ist als Strukturelement noch ein 
Multi-Link-Controller MLC eingefQhrt (an sich bekannt aus US 2003/0100961 A1). 

25 

In der Leitebene werden standig (Diagnose-) Informatlonen aus der Ebene der 
Prozessrechnerknoten 4 benOtigt. Dabei handelt es sich im wesentlichen um 
Systeminformationen wie Status- und Fehlermeldungen, Wartungsinformationen sowie 
Aufeeichnungen zur QualitatsQberwachung. Zur Auswertung der Daten steht in der 
30 Leitebene der in Figur 2 gezeichnete Diagnose-Rechnerknoten zur VerfDgung. Auch 
hier wird das an sich bekannte Ethernet als Kommunikationsmedium sowohl zu den 
einzelnen Prozessrechnerknoten 4 als auch zu den Diagnosestationen in der 
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Leitebene zur Verfugung gestellt, welche Client-Rechnerknoten mit 
Benutzeroberfiachen bilden konnen. Das an sich bekannte OSI-Schichtenmodell 
ermOglicht komplexe Kommunikationsmechanismen zwischen Prozessrechner- und 
Leitebene. Da die Diagnose unabhSngig von der restlichen Kommunikation erfolgen 
soil, ist jeder Prozessreclinerknoten 4 Gber das Ethernet vom Diagnoserechnerknoten 
(und umgekehrt) erreichbar. Damit wird u. a. der Vorteil erzielt, dass auch 
Kommunikationsproblenrie im synclironlsierten Ringbus der Prozessrechnerknoten 
untereinander erkannt werden kOnnen. 

Definition wiclitlger Begriffe: 

Ereignis Ein Ereignis ist eine Infomiatlon die von einem 

Antriebsregler (Prozessreclinerknoten am teclinisch- 
physikalischen Prozess) beim Auftreten an den Dlagnose- 
Server (Diagnosereclinerknoten) gesendet wird. Es 
erscheint in der Ereignisanzeige der Bedienoberfiache und 
im Logbuch. Ereignisse sind z.B. Fehlermeldungen. 
l\/leldungen Qber den Start/ Stop von Aufeeichnungen, 
Wartungsmeldungen etc. Jedes Ereignis hat eine 
eindeutige Ereigniskennung Qber die eine 
Ereignisbeschreibung in der Dokumentation abgerufen 
werden kann. 

Aufzelchnung Mit einer Aufzeichnung kann man beliebige 

Parameterverlaufe von beliebigen Reglern erfassen und in 
einer Datenbank speichern. 

Oberwacliungsansicht Die Oberwachungsansicht ist eine graphigche Darsteilung 

eines oder mehrerer Parameter von einem oder mehrerer 
Regler. Sie dient dazu, den Werteverlauf dieser Parameter 
hinsichtlich Abweichungen von der Norm zu uberwaclnen. 
(Z.B. Oberwachung der l\/lotortemperatur) 
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Parameterliste Die Parameterliste enthalt alle an einem Reglertyp 

vorhandenen Parameter 



Langzeitaufzeichnung Eine Aufeeichnung, deren Daten auf dam Diagnoseserver in 

einer Datenbank gespeichert werden. Gegenteil zur 
Ringspeicheraufeeichnung 

Ringspeicheraufzeich- Eine Aufeeichnung, deren Daten in einem Ringspeiciier des 
nung Prozessrechnerknotens gespeichert werden. Erst nach 

Beenden der Aufeeichnung kSnnen die Daten auf dem 

Diagnose-Server gespeichert werden. 

Konfigurations-Wizard Eine Abfolge von einzelnen Seiten auf denen der Benuteer 

Einstellungen vornehmen kann. Jeder Schiitt in der 
Konfiguration umfasst eine Anzahl von Funktionen und wird 
auf einer Seite dargestellt. Je nachdem wie der Benuteer 
sich im vorherlgen Schritt verhalt, wird eine entsprechende 
Nachfolgeseite angezeigt. (z.B. bei Konfiguration der 
Aufeeichnung: Auswahlmoglichkeit im Schritt 1: 
Ringspeicher oder Langzeitaufeeichnung: Je nach Auswahl 
bekommt der Anwender Seiten fur die Konfiguration des 
Ringspeichers oder der Langzeitaufzeichnung angezeigt.) 



Figur 3 gibt einen Qberblick Qber die Grobstruktur des Diagnosesystems. Dem 
5 Anwender stehen verschiedene web-basierte Bedienoberfiachen zur VerfQgung, die 
ihm die Funktionalitat des Diagnosesystem in einer fur ihn geeigneten Darstellung 
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prasentieren. FQr die Bedienung des Systems ist es unerheblich, ob sich der Benutzer 
lokal an der Aniage Oder an einem anderen Ort befindet 

Die vom Benutzer gewQnschten Funktionen warden von den Benutzeroberfiachen an 
den Diagnose-Rechnerknoten weitergeleitet Hier ist jede Funktlonalitat. die in der 

5 Oberfiache zur VerfQgung steht, implementiert. Weiter Qbernimmt der Diagnose- 
Rechnerknoten die Speicherung von alien anfallenden Daten in der Datenbank DB. 
Alle aniagenspezifischen Daten wie z.B. die Aniagenkonfiguration oder 
Bauteildatenbanken. alle diagnosespezifischen Daten wie z.B. Langzeltaufzeichnungen 
Oder Ringspelcherdaten sowie anwendungsbezogene Daten werden in der Datenbank 

10 DB venA^altet. 

Wefden von der Steuerung oder vom Leitstand beispielsweise einer Druckmaschine fOr 
die Diagnose relevante Informationen zur VerfQgung gestellt, konnen sie durch 
spezielle in dem Diagnose-Rechnerknoten integrierte Komponenten weiterverarbeitet 
werden. 

15 Die von der Bedienoberflache am Diagnose-Rechnerknoten eingehenden Auftrage 
werden dort verarbeitet und in fur die entsprechenden Regler verstandliche Befehle 
umgesetzt. Die Kommunikation zwischen Diagnose-Rechnerknoten und 
Kommunikations-Rechnerknoten mit angeschlossenem Regler erfolgt Qber Ethernet 
und darauf aufsetzende XML-Protokolle. Am Kommunikations-Rechnerknoten werden 

20 die vom Application-Server empfangenen Auftrage ausgefOhrt und das Ergebnis an 
den Diagnose-Rechnerknoten zurQckgeschickt. 

Jeder der unterstutzten Prozessrechnerknoten, beispielsweise Regler, muss eine xml- 
basierte Schnittstelle bieten. urn dem Diagnose-Rechnerknoten den Zugriff auf die 
benotigten Daten zu emnOglichen. Dies kann z.B. mit Hilfe eines Kommunikations- 

25 Rechnerknotens („Kommunikations-PC") realisiert werden, der entweder im Prozess- 
Rechnerknoten integriert ist (z.B. b maXX 4600) oder dem Prozess-Rechnerknoten als 
Einsteckkarte zugefugt wird. Alternativ kann die xml-basierte Schnittstelle des Prozess- 
Rechnerknotens auch ohne Kommunikations-PC-Hardware als Teil des Diagnose- 
Rechnerknoten laufen. Die Kommunikation zwischen den Schnittstellen-Modulen auf 

30 dem Diagnose-Rechnerknoten und der Prozess-Rechnerknoten-Hardware erfolgt dann 
Qber proprietare Protokolle und RS232 oder Ethernet 
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Die eingangs genannten Anforderungen bedingen eine komponentenbasierte, verteilte 
Architektur des Diagnosesystems. Gem§B den allgemeinen Grundsatzen der 
Softwareentwicklung werden die Datenerfassung, die Datenverarbeitung und - 
spelchemng und die Benutzeroberfiachen modularisiert und voneinander getrennt. 
Dadurcin wird eine Qberslchtliche und besser skallerbare Struktur erreicht, die leicht urn 
weitere Funktionalitaten erweltert werden kann. Hierdurch kann gewaiirleistet werden, 
dass das Diagnosesystem mit stelgender Anzalil von Antrieben „mitwachst" 
(Skalierbarkeit). Durch die Venwendung von Ethernet und TCP/IP fQr die 
Kommunikation zwischen den Kommuriikations-PCs. dem DIagnose-Rechnerknoten 
und den Anwendungen steht eine wesentlich liOhere Bandbreite zur DatenObertragung 
zur VerfDgung. Daraus resultiert ein Im Vergleich zur eingangs genannten DE 196 14 
748 wesentlich schnelleres Diagnosesystem. 

Weiter erieichtert die komponentenbasierte Stmktur den grolien Funktionsumfang des 
Diagnosesystems abzudecken. FQr jede Benutzergruppe kann eine eigens auf die 
BedQrfnisse zugeschnittene Bedienoberfiache entwickelt werden, die auf die darunter 
liegende Infrastruktur (DIagnose-Rechnerknoten) zugrelft. 

Durch die Trennung von Bedienoberfiache und Implementlerung der Funktionalitat im 
Diagnose-Rechnerknoten kennen neue Anwendungen zukQnftig mit wenlger Aufwand 
entwickelt werden. Durch Nutzung moderner Softwaretechnologien kann das Internet 
als weltweit verfugbares und akzeptiertes Kommunikationsmedium genutzt werden. 
Damit ist es unerheblich, ob die Oberwachung der Aniage lokal vor Ort oder von einem 
anderen Ort, wie z.B. dem Serviceburo durchgefuhrt wird. Durch die Nutzung von 
gangigen Internetbrowsern fQr die Benutzeroberflachen wird der Installationsaufwand 
beim Anwender wesentlich reduziert und die HOrde fQr den Anwender das 
Diagnosesystem zu benutzen deutlich herabgesetzt. 

Die komponentenbasierte Architektur ermSglicht welterhin die Unterstutzung von neu 
entwickelten Verfahren zur Obenwachung und Diagnose von Antrieben, indem neue 
Funktionen als Komponente in den Diagnose-Rechnerknoten eingebunden werden. 
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Wesentliche Vorteile des erfindungsgemaBen Diagnosesystems bestehen 
insbesondere in folgendem: 

(1) Der Kunde hat durch die Weboberfiache einen universellen Zugriff auf die 
5 Diagnosefunktlonen: 

• Die richtige Information zeitnah am richtlgen Ort 

• Einfache Bedienoberfiache durch Webbrowser 

• BenutzerfQhnjng erieichtert die Bedienung und Konfiguration 

• Die Web-Oberfiache ist plattformunabhangig 

10 • Bedienung Qber das Internet mOgiich, sofern gewunscht 

(2) Der Kunde bekommt fQr ihn aufbereitete Informationen Qber den Zustand der 
Aniage: 

• Informationsaufbereitung in Form von graphische Darstellungen 
15 • Vorbeugende Diagnose 

(3) Die wesentlich erweiterten DiagnosemOglichkeiten emi6glichen: 

• Erweiterte Oberwachung der Aniage 

• Einfachere Lokalisierung der Ursache im Fehlerfall 

20 (4) Die Funktionen zur inbetriebnahmeunterstotzung ermOglichen: 

• Schnellere Inbetriebnahme -> Kostenreduzierung 

• Erhtthte Qualitat der Inbetriebnahme durch definierte und dokumentierte 
Abnahmeprotokolle 

25 EIne Funktionsgruppe Softwareupdate ermOglicht das Installieren oder Aktualisieren 
einer Firmware des Prozess-Rechnerknotens beispielsweise zur Firmware. Alle 
durchgefOhrten Aktlonen in dieser Funktionsgruppe werden In einem Logfile erfasst, 
Voraussetzung fQr die Installation Oder Aktualisierung der Finnware ist, dass die 
ausgewahlten Regler eine eindeutige Reglerkennung besitzen. Folgende Aktionen 

30 mOssen mOglich sein: 
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1 . Antriebe auswahlen 

Der Benutzer wahit die zu aktualisierenden Antriebe aus eine Antriebsliste aus. 

2. Firmware auswShlen 

Der Benutzer wahit die Firnnware, die auf die zu aktualisierenden Antriebe 
5 geladen werden soil aus. 

3. DurchfQIiren des Softwareupdates 

Nach der Anzeige eines Warnliinweises wird das Softwareupdate durchgefQhrt. 

Eine Funktionsgruppe ^Events konfigurieren" bietet die Moglichkeit, beliebige 
10 Ereignisse in der Ereignisanzeige und im Logbuch aufzuzeiclinen. Der im 
Kommunikations-PC des jeweils Prozess-Reclinerknotens vorfiandene Event(Ereignis)- 
Broker wird mit Hilfe der unter genannten Funktionen konfiguriert, so dass er die 
gewQnschten Parameterkombinatlonen auf das Eintreten des konfigurierten 
Ereignissfes Qberwacht. Beim Eintreten des Ereignisses wird es an den Diagnose- 
15 Rechnerknoten geschickt und dort in der Ereignisanzeige angezeigt Folgende 
Aktionen konnen beispielsweise meglich sein: 

1 . Antriebe auswalilen 

Der Benutzer wahit die Antrieb aus, fUr die ein Event konfiguriert Oder geioscht werden 
soli. 

20 2. Event konfigurieren 

Der Benutzer konfiguriert ein Ereignis mit Hilfe eines Konfigurations-Wizards 

3. Event lOschen 

Der Benutzer IGscht einen Event aus eine Liste mit laufenden Events. 

StandardmaBig vorhandene Events, wie z.B. Fehler kfinnen nicht gelSscht 
25 werden. 

4. Eventkonfiguration zum Antrieb schicken 

Der Benutzer schickt den konfigurierten Event zu einer Antriebsauswahl und 
aktiviert ihn. 
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Eine Funktionsgruppe „Skripte" bietet die Moglichkeit komplexe Diagnosefunktionen 
durchzufQhren. Um komplexe Abfragen von Parametern zu realisieren konnen PERL- 
Skripte geschrieben werden. die auf den entsprechenden Kommunikations-PC 
geschickt werden und dort ausgefQhrt werden. Folgende Aktionen sollen mCglich sein: 

5 1 Laden des Skripts auf den Server 

Der Benutzer ladt das Skript von dem Kommunikations-PC eines Antriebs auf den 
Server. 

2 Laden des Skripts zum Antrieb 

Der Benutzer ladt ein aus einer LIste ausgewahltes Skript auf einen ausgewaiilten 
10 Antrieb. 

3 Skript editleren 

Der Benutzer editiert ein Skript 

4 AusfUhren des Skripts auf dem Kommunikations-PC 
Der Benutzer startet das Skript auf einem Antrieb. 

15 

Nachfolgend wird ein Oberblick Qber die Architektur des Diagnose-Rechnerknotens des 
Diagnosesystems gegeben. Figur 1 zeigt eine detaillierte Stnjktur des 
Dlagnosesystems Sie bestelit im wesentlichen aus drei Ebenen: 

20 Client-Rechnerknoten mit Bedienoberflachen; 

Alle Funktionalitaten des Diagnosesystems kOnnen Qber die Bedlenoberfiaciien 
bedient werden. FQr den Benutzer des Diagnosesystems soil es keinen Unterschied 
machen, ob er s\ch im lokalen Netz an der Aniage befindet oder Qber das Internet oder 
eine Telefon-Einwahlverbindung mit dem Application-Server verbunden ist. 

25 

DIagnose-Rechnerknoten 

Dieser stellt den Kern der gesamten Anwendung dar. Seine Funktionalitat ist in 
verschiedene Komponenten (IVIanager) unterteilt. Jeder IVIanager ist in sich 
abgeschlossen und stellt seine Funktionalitat der webbasierten Bedienoberfiache oder 
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anderen Serverkomponenten zur VerfDgung. Alle fOr die Funktion des Managers 
notwendigen Daten werden in der angesclilossenen Datenbank gespeiciiert. Urn die 
Kapselung und Konsistenz dieser Daten zu gewahrleisten kann auf diese 
Datenbestande nur Qber die vom Manager zur VerfDgung gestellten Funktionen 
zugegriffen werden. Dadurch wird auch sichergestellt, dass eine Anderung an der 
Datenbankstmktur eines Managers nicht unbedingt Anderungen an anderen Managem 
nach sich zleht. 

Um die Funktlonalitaten der Manager den Bedienoberfiachen zur VerfOgung zu stellen 
muss eine geelgnete Infirastruktur geschaffen werden. (Tomcat Servlet-Container) FQr 
die Kommunikation mit der Weboberfiache zur inbetriebnahme, Obenwacliung und 
Diagnose soil ein Apache Webserver eingesetzt werden. Dieser stellt HTML-Seiten zur 
VerfDgung , In die Java-Applets eingebettet sind. Die auf der Oberfiaclie 
anzuzeigenden Daten werden mit Hilfe von Soap (Simple Object Application-Protokoll) 
zu den entsprechenden Modulen Qbertragen. Die BenutzeroberflSche ruft z.B.. eine 
Funktion des Anlagen-Managers auf. Die zu Qbergebenden Parameter und die 
Bezeichnung der Funktion wird mit Hilfe des Soap Protokolls auf das Intra- Oder 
Internet geschickt. Um die Transparenz ganglger Firewalls zu gewahrleisten, wird der 
Funktionsaufi-uf in Form eines HTTP-Telegramms verschickt. Ein Webserver auf der 
Seite des Application-Servers empfangt die HTTP-Telegramme mit dem Soap-lnhalt 
und leitet sie an den Soap-Handler weiter. Der Soap-Handler im Tomcat-Servlet 
Container decodierl die Anfrage und ruft die gewQnsclite Funktion aus dem Anlagen- 
Manager auf. Die Funktion wird ausgefGhrt und die RQckgabewerte wiederum in das 
Soap Protokoll umgesetzt und als HTTP-Telegramm an die Oberfiache geschickt. 

Eine wesentliche Eigenschaft eines Diagnose- und Oberwachungssystems ist, dass der 
Benutzer uber an der Aniage auftretende Ereignisse zeitnah informiert wird. Dies stellt 
for die oben gezeigte Architektur eine Schwierigkeit dar, da sowohl fQr die 
Kommunikation Qber Soap als auch fUr die HTML-Seiten eine ereignisbasierte 
Benachrichtigung nicht vorgesehen ist. Als Abhilfe mOssen an der Aniage auftretende 
Ereignisse. wie z.B. das Auftreten eines Fehlers oder das Update eines 
Parametenwertes in einer Oberfiache. Qber einen Event-Kanal den 
Benutzeroberfiachen mitgeteilt werden oder standig gepollt werden. 
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Prozessrechner-Knoten 

Die Prozess-Rechnerknoten-Ebene stellt dem Diagnose-Rechnerknoten die Daten von 
den Prozess-Reclinerlcnoten zur VerfQgung. Es soli der Prozess-Redinerknoten 
angebunden wertlen. Wie berelts angedeutet, besteint der Diagnose-Reclinerknoten 
aus verschledenen gekapselten Serverkomponenten (IVlanager), die ihre 
Funktionalitaten Ober den Tomcat-Servlet-Container der Benutzeroberfiache 
beziehungsweise Ciient-Reciinerknoten zur VerfQgung steilen. Durcii die 
komponentenbasierte Stmktur soil sicliergesteiit werden. dass der Funktlonsumfang 
des Diagnosesystems enweltert werden kann. Die Manager sind als Java-Komponenten 
reaiisiert Im Folgenden werden die einzelnen Manager beschrieben. 

Der Aniagen-Manager enthait aiie notwendigen Daten Uber die Konfiguration der 
Aniage. Dies beinhaltet Daten Qber die In der Aniage vorhandenen Komponenten. 
Gruppierung der Komponenten. Adressen etc. Es sollen Funktionalitaten zur VerfQgung 
gestellt werden, die die Darstellung der Aniagenkonfiguration in Form verscliiedener 
Obersichtsbilder eriauben. Weiteriiin sollen alle Dokumentationen zu den in der Aniage 
enthaltenen Daten zur VerfQgung gestellt werden. 

Belm Entwurf des Aniage n-Managers 1st darauf zu achten, dass mit Hilfe der 
Funktionalitaten dieser Komponente beliebige Aniagen Im Bereicli der Antriebstechnik 
beschrieben werden kbnnen. 

Der Ereignis-Manager venwaltet alle Im DIagnosesystem auftretenden Ereignisse wie 
Z.B. Fehlermeldungen Oder Wartungsereignisse. Er sammelt alle aufgetretenen 
Ereignisse in Form von LogbQchem und stellt sie dem Benutzer in einer 
konfigurierbaren Darstellung zur VerfQgung. Weiterhin besitzt der Ereignis-Manager 
Funktlonen mit deren Hilfe beliebige EreignisQbenwachungen definiert werden kSnnen, 
die dann vom Ereignis-Manager auf den entsprechenden Reglem konfiguriert werden. 
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Der Aufeeichnungs-Manager stellt Funktionen zur VerfDgung mit deren Hilfe beliebige 
Parameter von beliebigen Reglem aufgezeichnet warden kOnnen. Er bietet 
verschiedene Aufzeichnungstypen die von Benutzer konfiguriert warden kOnnen. Alle 
5 bei einer Aufeeichnung anfallenden Daten werden vom Aufeeichnungs-Manager In 
einer Datenbank gespeichert und auf Anforderung hin anderen Modulen, wie z.B. 
einem Graphlk-Modul der Oberfiache zur VerfQgung gesteilt 

Alle Funktlonalitaten im Diagnosesystem sind gegen unautorlslerten Zugriff geschQtzt. 

Jeder Benutzer hat eine Benutzerkennung und gehOrt zu einer Benuteergruppe, die 
10 Ihm ein Rechteprofll fQr den Zugriff auf die Funktionalltaten der Manager ermSglicht 

DIese Infomiationen werden Im Benuteer-Manager konfiguriert und abgespelchert. 

Jede Funktlon In den Managem hat eine eindeutige Kennung. Will ein Benutzer auf 

eine Funktlon zugreifen. wird zunachst am Benutzer-Manager nachgefragt ob der 

Benutzer die entsprechenden Rechte fQr das AusfQhren dieser Funktlon besltzt. Die 
15 Datenbank in der die Benutzerdaten abgelegt werden soil durch VerschlQsselung vor 

unberechtigtem Zugriff geschutzt werden. 

Der Logging-l\/lanager sammelt alle Logging-Daten von den angeschlossenen Reglern 
und speichert derern Log- und Debug-Nachrichten in einer Datenbank Oder in 
20 rollierenden Logfiles ab. 

Der Kommunikatlons-Rechnerknoten beziehungswelse Kommunikatlons-PC gemaB 
Figur 5 Qbemimmt die Kommunlkationsaufgaben zwischen dem Prozess- 
Rechnerknoten und der AuBenwelt. Nachfolgend wird die Softwareslruktur fQr die 

25 Kommunikatlon zum Prozess-Rechneri<noten beschrieben. 

Jedes Gerat das mIt dem Prozess-Rechnerknoten kommunizieren soil, muss ihn Qber 
eine geeignete Software-Schnittstelle auf dem Kommunikatlons-PC ansprechen. Mit 
Hiife des Kommunlkatlons-PCs kann beinahe jede Software-Schnittstelle, die auf 
Ethernet Oder einer seriellen Schnittstelle basiert, realisiert werden. Nachfolgend wird 

30 die Softwarearchitektur auf dem Kommunlkations-PC beschrieben. Eine Einordnung in 
das Gesamtkonzept Ist den obigen AusfQhrungen zu entnehmen. Die Figur 5 zeigt die 
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Softwarestmktur auf dem Kommunikations-PC beziehungsweise Prozess- 
Rechnerknoten. 

Jede Funktionalitat, die vom Prozess-Rechnerknoten der AuSenwelt zur VerfOgung 
5 gestellt werden soli, ist In einem Softwaremodul (Informations-Broker oder Manager) 
reaiisiert. Z.B. stellt der Informations-Broker ^Parameter" eine Parameterschnittstelle 
zur VerfOgung Uber die beliebige Parameter des Prozess-Rechnerknotens gelesen 
- und geschrieben werden kOnnen. Der Informations-Broker „Fehler und Events" stellt 
beliebige Ereignisse und Fehler nach auBen dar. Die beiden Informations-Broker 
0 „Parameter-Bedarfedaten" und „Zyklische Sollwerte" eriedlgen die Kommunikation 
mit der Steuerung. Sie sind nur auf den Reglern vorhanden. die den Master im 
Seroos-Ring bilden und somit mit der Steuerung kommunizieren mOssen. Der 
Informations-Broker „Software-Download" stellt Funktionen fQr einen automatischen 
Up- und Download der Regler-Firmware bereit. Ein (nicht gezeichneter) Parameter- 
is Manager dient zur intemen Verwaltung der Reglerparameter auf der Flaslikarte. Er 
istfOr die Kommunikation mit der AuBenwelt nicht relevant. 

Die Kommunikation der Informations-Broker „Parameter, „Fehler und Evenf sowie 
„Softwaredownload" mit der AuBenwelt erfoigt Qber XML-basierte Protokolle. Alle 
zo Anfragen bzw. Antworten werden in, mit Hilfe eines XML-Schemas deflnlerten, XML- 
Nachrichten Qbertragen. 

Jeder der vorhandenen Broker kann gleiclizeitig mehrere Anfragen von einem Oder 
verschiedenen Clients bearbeiten. Im Wesentlichen kommuniziert der 

25 Kommunikations-PC des Prozess-Rechnerknotens mit der Steuerung und dem 
Diagnose-Rechnerknoten. In der Kommunikation mit einer SPS-Steuerung muss 
sichergestellt werden, dass die Nachrichten in jedem Fall ohne unnOtigen Zeitverzug 
an einem Prozessor des Prozess-Rechnerknotens verarbeitet werden, da sie fur den 
Betrieb der Aniage von wesentllcher Bedeutung sind. Nachdem die Anfragen auf 

30 dem Prozessor des Prozess-Rechnerknoten nur sequentiell verarbeitet werden 
kOnnen, muss die MOglichkeit bestehen. Anfragen von der SPS-Steuerung vorrangig 
zu bearbeiten. Dies soli durch Vergabe von Priorltaten fQr die Anfragen sichergestellt 
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werden. Jede Anfrage an einen der Broker am Kommunikations-PC ist mit einer 
Prioritat versehen. GemaB dieser Prioritat wird die Anfrage bevorzugt Oder 
nachrangig behandelt. 

5 Neben den Inforniations-Brokern gibt es weitere, zum Teil optionale, Softwaremodule 
auf dem Kommunlkations-PC: 

• Ein Logging-Server empfangt Log- und Debugnachrichten von den 
Informations-Brokem und stellt sie der AuBenwelt zur VerfQgung. 

• Ein Webserver bletet eine einfache Weboberflaclie zur Bedienung und 
10 Konfiguration. 

• Ein FTP-Server dient zum einfachen Up- und Download von Firmware auf den 
Prozess-Rechnerknoten. 

• Ein Ciient zur Zeitsynclironisation sorgt fQr eine Obereinstimmende Zeit auf 
alien Kommunikatlons-PCs einer Aniage. 

13 - Mit Hilfe eines Perl-Interpreters konnen belleblge Skripte mIt Diagnose- oder 

Steuerungsfunktionalitaten ausgefQhrt werden. 

• Der Konfiguratlons-Manager eriedigt das Starten wichtiger Dienste (z.B. 
automatlsche Konfiguration einer ErelgnisQberwachung fOr einen Fehler im 
technisch-pliysikalischen Prozess) sowie die Veraraltung der 

20 Konflgurationsdaten der einzelnen Softwaremodule. 

• Ein Telnet-Zugang steht fQr Wartungszwecke zur VerfQgung. 

Im Folgenden werden die Softwaremodule des Kommunikatlons-PCs bechrieben. 

25 Aufgabe des Informations-Brokers .Parameter" ist die Bereitstellung einer XML- 
basierten Parameterschnittstelle fQr den Zugriff auf die Parameter des Prozess- 
Rechnerknotens. Als Protokoll kommt ein mit Hilfe eines XML-Schemas definiertes 
xml-basiertes Protokoll zum Einsatz, welches Qber TCP/IP mit dem Client 
kommuniziert. Aus der Sicht des Clients sollen folgende Funktionen gegeben sein: 



Lesen von Parametern 
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Der Informations-Broker „Parameter'' soil eine Gruppe von belleblgen Parametern 
vom Prozessor des Prozess-Rechnerknotens lesen k6nnen. Hierbei soil neben dem 
einmaligen Lesen ein zyklisches Lesen von Parametern mOglich sein. Das Intervall 
zwischen den Lesevorgangen und die Anzahl der Lesevorgange sollen vom Client 
5 elnstellbar sein. 

Schreiben von Parametern 

Der Informations-Broker „Parameter* soil eine Gruppe von beliebigen Parametern auf 
den Prozess-Rechnerknoten schreiben kOnnen. 

10 

Aufgabe des Informations-Brokers „Fehler und Events" ist die Bereitstellung einer xml- 
basierten Schnittstelle Qber die ein Client Qber am Regler auftretende Ereignisse 
informiert wird, ohne dass er standig am Regler anfiragen muss. Als Protokoll kommt 
ein mit Hilfe eines XIVIL-Schemas definiertes xml-basiertes Protokoll zum Einsatz, 
15 welches Qber TCP/IP mit dem Client kommunizlert. Aus der Sicht des Clients sollen 
folgende Funktionen verFQgbar sein: 

Konfigurieren einer EreignisQbenA^achung 

Am Informations-Broker „Evenf soli es mfiglich sein. beliebige Eintrittsbedingungen fur 
20 ein Ereignis zu definieren, bei deren Elntreten eine Nachricht an den Client verschickt 
wird. Falls das Ereignis eingetreten ist, sollen zusStzlich zu den an der 
Eintrittsbedingung beteiligten Parametern noch weitere Parameter vom Regler 
abgefragtwerden konnen. 

Ein erfolgreich entgegen genommener Auftrag soli vom Broker bestatigt werden. 

25 

Der Informations-Broker „Event" soil umfangreiche Funktionalitaten besitzen die dem 
Client weitreichende MOglichkeiten bieten, Eintrittsbedingungen zu bilden. Eine 
Eintrittsbedingung soil aus mehreren Teilbedingungen zusammengesetzt sein, die 
miteinander logisch UND oder ODER verknQpft werden kOnnen. Innerhalb jeder 
30 Teilbedingung kann der aktueli gelesene Wert des Parameters entweder mit einem. in 
der Konfigurationsnachricht mitgeschickten Vergleichswert oder mit dem letzten 
gelesenen Parameterwert verglichen werden. Optional soli ein Toleranzlimit 
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berijcksichtigt werden kOnnen, das mit dem Vergleichswert verrechnet wird. Es sollen 
far den Vergleich sowohl alle logischen Operatoren (<. >, <=, >=. !=) sowie der 
Vergleich mit einer Bitmaske realisiert werden. Zusatzlich soil fQr jede Teilbedingung 
ein Triggennodus berQcksichtigt werden, der angibt, ob das Ereignis beim erstmaligen 
5 Eintreffen der Ereignisbedingung, beim Verschwinden einer bereits eingetretenen 
Bedingung oder in beiden Fallen gesendet werden soil. 
Melden eines Erelgnisses 

Beim Eintreffen der konfigurierten Ereignisbedingung soli eine XML-Nachricht an den 
Client gesendet werden. 

10 

Beenden einer Ereignisuberwachung 

Mit Hilfe einer dafur vorgesehenen XML-Nachricht kann eine laufende 
EreignisQberwachung beendet werden. 

15 Abfrage des Status einer EreignisQbenA/achung 

Mit Hilfe einer dafOr vorgesehenen XML-Nachricht kann der Client beim Informations- 
Broker „Evenf anfragen, ob eine EreignisQberwachung lauft oder bereits beendet 
wurde. 

20 Ein Unterschied zum Informations-Broker ^Parameter** 1st, dass zum Client keine 
permanente Socket-Verbindung besteht Nach der Konfiguration des Events wird diese 
abgebaut und erst beim Auftreten des konfigurierten Events wieder aufgebaut. HierfOr 
muss auf der Seite des Clients ein entsprechender Server-Port zur VerfQgung stehen. 

25 Der Informations-Broker „Zyklische Sollwerte" erledigt einen Teil der Kommunikation 
mit der Steuerung. Er kommt insbesondere bei Druckmaschinen Anwendungen zum 
Einsatz, sofern es sich um einen Prozess-Rechnerknoten beziehungsweise Regler 
handelt, der Sercos-Master in einem Antriebsring ist 

Aufgabe des Informations-Brokers „Zyklische Sollwerte" ist es, den Regler in 
30 regelmaliigen Zeltintervallen mit neuen Sollwerten von der Steuerung zu versorgen. 
Dabei empfSngt er die von der Steuerung gesendeten Telegramme und leitet sie an 
den Regler weiter. Er soil folgende Fahigkeiten besitzen: 
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Empfeng der Sollwert-Telegramme von einer oder mehreren Steuemngen 
Der Informations-Broker „Zyklische Sollwerte" soil In der Lage sein, Sollwert- 
Telegramme von eIner oder mehreren Steuerungen zu empfangen. Die Kommunikation 
5 mit der Steuerung kann Qber ein proprietares Protokoll und/oder das Protokoll UDP/IP 
laufen. 

Weiterleltung der Sollwerte an den Regler 

Alle von einer Steuemng SPS empfangenen Sollwerttelegramme sollen mit der 
10 hSchsten Prioritat an den Prozess-Rechnerknoten beziehungsweise Regler 
weitergeleitet werden. 

Monitoring der Sollwert-Telegramme 

For Diagnosezwecke soli es mOglidi sein, die ankommenden Telegramme von der 
15 Steuerung neben der Weiterleltung an den Regler zusatzlich aucli an das 
Diagnosesystem welterzugeben. 

Der Informations-Broker „Parameter-Bedarfsdaten" eriedlgt einen Teil der 
Kommunikation mit der Steuerung. Er kommt insbesondere bei Druckmaschinen- 
20 Anwendungen zum Einsatz, sofem es sich um einen Prozess-Reclinerknoten oder 
Regler handelt, der Sercos-Master in einem Antriebsring 1st. 

Aufgabe des Informations-Brokers ..Parameter-Bedarfisdaten" ist es einer oder 
mehreren Steuerungen beliebige Parameterwerte zeitnah zur VerfQgung zu stellen. Er 
soli folgende FShigkeiten besitzen: 

25 Lesen von Parametern 

EIn Steuerungsclient schickt beliebige Parameter in einem Anforderungstelegramm an 
den Informations-Broker. Dieser fragt die Parameterwerte mit einer hohen Prioritat vom 
Regler ab und sendet ein Antworttelegramm an den Steueaingsclient zurUck. FQr die 
Kommunikation mit dem Steuerungsclient kann eIn proprietares Protokoll und/oder 

30 TCP/IP zum Einsatz kommen. 



Monitoring der Anforderungstelegramme 
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FDr Diagnosezwecke soli es mSglich sein, die ankommenden Telegramme von der 
Steuerung neben der Weiterieitung an den Prozess-Rechnerknoten oder Regler 
zusatzlich auch an das Diagnosesystem weiterzugeben. 

Aufgabe des Infomiations-Brokers ..Softwaredownload" ist die Obertragung der 
Reglerfirmware sowie kompletter Datensatze zwischen dem Diagnose-Rechnerknoten 
und dem Regler. Die Obertragung der Daten erfolgt mit Hilfe des ftp-Protokolls. Er soli 
folgende Fdhigkeiten besitzen: 

Download einer Reglerfirmware auf den Regler als Prozess-Rechnerknoten 
Der Download von Reglerfinnware erfolgt in zwei Schritten: ZunSchst wird mit Hilfe 
eines ftp-Clients die Flmiware in ein Verzeichnis auf der Flashkarte des 
Kommunikations-PCs Qbertragen. Im zweiten Schritt wird der Infomnatlons-Broker 
.Softwaredownload" mit Hilfe eines XML-Telegramms angewiesen die 
Booteinstellungen des Reglers so zu verSndern, so dass belm nachsten Booten des 
Reglers die neue Firmware gestartet wird. 

Upload einer Reglerfirmware vom Regler als Prozess-Rechnerknoten 

Der Upload ©Iner Reglerfirmware erfolgt direkt Qber das ftp-Protokoll. Hierbei ist keine 

UnterstQtzung von Seiten des Infomiations-Brokers .Softwaredownload" notwendlg. 

Download eines kompletten Datensatzes 

Wie beim Download einer Reglerfirmware erfolgt auch der Download eines Parameter- 

Datensatzes in zwei Schritten: 

Zunachst wird mit Hilfe eines ftp-Clients der Datensalz in ein Verzeichnis auf der 
Flashkarte des Kommunikations-PCs Qbertragen. Im zweiten Schritt wird der 
Informations-Broker „Softwaredownload° mit Hilfe eines XML-Telegramms angewiesen 
die Einstellungen des Reglers so zu verandern, so dass beim nachsten Booten des 
Reglers der neue Datensatz berQcksichtigt wird. 



Upload eines kompletten Datensatzes 
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Der Upload eines Datensatzes erfolgt direkt Qber das ftp-Protokoll. Hierbei ist keine 
UnterstQtzung von Seiten des Informations-Brokers „Soflwaredownload" notwendig. 

Aufgabe des Connection-Managers Ist es, die Schnittstelle zum Regler 
5 beziehungsweise Prozess-Rechnerknoten zu verwaiten. Hierbei soli es moglich sein, 
verschiedene physikalische Schnittstellen zu verwaiten. (z.B. seriell, Ethernet oder SRI) 
Jede Anfrage an den Connection-Manager ist mit einer von 5 Prioritatsstufen versehen. 
Anfragen mit der hOchsten Prioritat werden vom Connection-Manager vor alien 
weiteren anstehenden Anfragen an den (digitalen Signal-) Prozessor Prozess- 
10 Rechnerknotens geschlckt. Anfragen mit niedriger Prioritat werden immer nach alien 
anderen anstehenden Auftragen behandelt Hierdurch kann sichergestellt werden, 
dass ein Auftrag mit hdchster Prioritat -z.B. von der Steuerung- in jedem Fall als 
nachste Anfrage auf dem Prozess-Rechnerknotens bearbeitet wird. 

15 Im Prozess-Rechnerknoten Ist als Speichemilttel eine Flash-Karte aufgrund der 
besseren UnterstQtzung durch den Intel PXA 255 dem Kommunikations-PC 
zugeordnet. Trotzdem muss fQr den Prozess-Rechnerknoten beziehungsweise Regler 
eine MSglichkeit bestehen Parameter von der Flash-Karte zu lesen sowie auf die 
Flash-Karte zu schrelben. Dies wird mit Hilfe des Parameter-Managers gewahrleistet. 

20 

Weitere Dienste auf dem Kommunikations-PC 
Logging Servers 

25 Alle Meldungen, die in den Informations-Broker-Prozessen erzeugt werden, werden 
formatiert und an die Konsole, in ein Logfile oder eine Nachrichtenwarteschlange des 
Log-Servers geschrieben. Von diesem Log-Server kSnnen die Nachrichten dann zu 
beliebigen Servem / Rechner verschickt werden. 

Um die spatere automatische Auswertung der Logfiles zu ermOglichen, werden 
30 verschiedene Nachrichtentypen definiert, die die Interpretation der Nachrichten 
erielchtem. (z.B. Debug, Daten, En-or ...) 
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SkriptunterstQtzung 

Mit Hilfe der SkriptunterstQtzung auf dem Kommunikations-PC soli eine flexible und frei 
programmierbare Schnittstelle geschaffen warden, mit der auch zukQnftlge 
Anforderungen an Oberwachung und Diagnose abgedeckt werden sollen. Mit Hilfe 

5 eines Perl-interpreters kOnnen bellebige Skripte auf dem Kommunikations-PC 
ablaufen, die auf die Funktionalitaten der Informations-Broker ^Parameter" und „Fehler 
und Events" zugreifen. So konnen komplexere Uberwachungsfunktionen lokal auf dem 
Kommunikations-PC ausgefOhrt werden ohne dali eine Belastung des Netzwerks durch 
Obertragung von Daten stattfindet. Die Skripte werden mit Hilfe des ftp-Servers auf 

10 dem Kommunikations-PC Ubertragen Oder sind dort schon als Tail der Software 
vorhanden. 

Wegen der hohen Anforderungen an Performance und Systemressourcen des 
Kommunikations-PCs soil die SkriptunterstQtzung nur fOr spezielle Diagnoseaufgaben 
verwendet werden. 

15 

Zeitsynchronisation. FTP-Server, Telnet 

FQr die Synchronisierung der Systemzeiten sollen alle Kommunikations-PCs ihre 
Systemzeit regelmaiiig Qber einen auf dem BAUDIS Server laufenden Zeitserver 
synchronisieren. 

20 Der FTP-Server und der Telnet-Zugang dienen fOr das Software-Update des 
Kommunikations-PCs und zur Wartung. 

Wahrend des Betrlebs des Antrlebssystems entstehende Diagnosedaten (z. B. Fehler 
Oder Diagnoseinformationen wie z. B. Temperatur, Geschwindigkeit. Schleppfehler, 
25 Regelabweichung) werden vom Kommunikations-PC auf dem Prozessrechnerknoten 
bzw. Antriebsregler gepollt und in ein xml-basiertes Protokoll umgewandeit. Der 
Kommunikations-PC stellt die Diagnosedaten ereignisbasiert (Informations-Broker 
„Evenf) Oder anfragebasiert (Informations-Broker „Parameter") dem 
Diagnoserechnerknoten zur VerfOgung. 

30 

In den Managern des Diagnoserechnerknotens werden die Diagnosedaten von den 
Kommunikations-PCs der Antriebsregler geholt bzw. ereignisbasiert empfangen und 
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weiterverarbeitet (z. B. Abspeichern in der Datenbank, Umrechnen etc.). Sollen 
Diagnosedaten auf der Benutzeroberfiache angezeigt werden, leitet der Manager die 
Diagnosedaten an die entsprechende Komponente im Sen/let Container waiter. Dort 
werden die Daten aufbereitet, so dass sie mit Hilfe von anfragenbasierter 
5 Kommunikation (Polling) Oder mlt Hilfe von ereignisbasierter Kommunikation (Event- 
Kanal) Qber die Datenfernverbindung zu den Java-Applets, die in der 
Benutzeroberfiachen eingebettet sind, Qbertragen werden konnen. 

Figuren 6 und 7 zeigen webbasierte Bedienoberflachen. welche die benOtigten 
10 Diagnose-lnformationen for die Benutzer grafisch aufbereiten. Dadurch wird das 
erfindungsgemSBe Diagnosesystenn zu einem Instalment. das die 
MaschlnenverfQgbarkelt erhOht und auch komplexe Anlagen mit einer Vielzahl von 
Antrleben beherrschbar macht So kann mit Bedienoberflachen nach Art des in Figur 7 
und 8 gezeigten der Maschinenleitstand mit Daten fur den aktuellen Maschlnenstatus. 
15 Oder die Produktionsleltung mlt statistlschen Daten zur MaschinenverfOgbarkeit und zu 
Wartungszyklen versorgt werden. Aber auch der Maschlnenhersteller Oder der 
AntriebsausrQster kann auf eine Aniage mit einer Vielzahl physikalisch-technlscher 
Prozesse so komfortabel zugreifen. urn im Servicefall schnelle und effiziente Diagnose 
und Fehlerbeseitigung zu gewShrleisten. Dies wird durch den Einsatz moderner Web- 
20 Technologien bzw. webbasierter Bedienoberflachen mit der ihnen innewohnenden 
Flexibilitat ermOglicht. Vorteilhaft kann so die Weboberflache auf jedem beliebigen 
Client-Rechner laufen, unabhSngig vom jeweiligen Client-Betriebssystem. Eine 
Installation einer fOr das Diagnosesystem spezifischen Bedienoberfiache auf dem 
Client-Rechnerknoten entfailt. Die webbasierten Bedienoberflachen sind aufgnjnd der 
25 weiten Verbreitung durch das Internet vom Benutzer in gewohnter und damit lelchter 
Weise bedienbar. Mit vertretbarem Aufwand kann die Bedienoberfiache an 
KundenwQnsche angepaBt werden (z. B. SprachunterstQtzung). 



Bezugszelchenliste 



30 



1 



Achse 



2 



Elektromotor 
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3 Wechselrichter 

4 Prozessrechnerknoten 

5 Kommunikationsrechnerknoten 

6 Schaltschrank 

5 SPS Steuerungsrechnerknoten 
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Patentansprtiche 



1. 

5 

10 
15 

2. 

20 

3. 

25 

4. 

30 



Rechner-Netzwerk zur Konfiguration, Inbetriebnahme, Oberwachung, Fehler- 
Dlagnose und/oder -Analyse mehrerer technisch-physikalischer Prozesse, 
insbesondere elektrischer Antriebsvorgange, die unter der Steuerung, Regelung 
und/oder Oberwachung durch mehrere Prozessrechnerknoten (4) ablaufen, 
welche Qber wenigstens ein gemelnsames Kommunikationssystem mit 
wenigstens einem Diagnoserechnerknoten verbunden sind, in dem ein Oder 
mehrere Konfigurations-, Obenwachungs-, Diagnosedienste und/oder -funktionen 
implementiert sind, die den Prozessen und/oder den Prozessrechnerknoten (4) 
und/oder den darin ablaufenden Datenverarbeitungsprozessen zugeordnet sind, 
dadurch gekennzeichnet, dass das gemeinsame Kommunikationssystem mit 
dem Ethernet oder einem sonstlgen, asynchron und/oder mit einem 
stochastischen Zugriffsverfahren arbeitenden Bus- oder Kommunikationssystem 
realisiert ist. 

Netzwerk nach Anspmch 1, dadurch gekennzeichnet, dass dem Ethemet oder 
dem sonstlgen Bus- oder Kommunikationssystem und wenigstens einem der 
Prozessrechnerknoten (4) ein Kommunikationsmodul oder -rechnerknoten 
zwischengeschaltet ist, das beziehungsweise der den Prozessrechnerknoten (4) 
an das Ethernet oder sonstige Bus- oder Kommunikationssystem anbindet 

Netzwerk nach Anspruch 2, dadurch gekennzeichnet, dass das 
Kommunikationsmodul oder der Kommunikationsrechnerknoten (5) zur anfrage- 
Oder ereignisbasierten Kommunikation mit dem Diagnoserechnerknoten 
ausgebiidet ist. 

Netzwerk nach Anspruch 2 oder 3, dadurch gekennzeichnet. dass das 
Kommunikationsmodul oder der Kommunikationsrechnerknoten (5) zur 
Kommunikation mit dem Diagnoserechnerknoten Qber XML-Protokolle und/oder 
als XMUbasierte Schnittstelle ausgebiidet ist. 
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Netzwerk nach einem der AnsprOche 2 bis 4, dadurch gekennzeichnet, dass das 
Kommunikationsmodul ganz oder teilweise auf der Hardware des 
ProzeBrechner- und/oder Diagnoserechnerknotens ablauffahig ist. 

Netzwerk nach einem der AnsprQche 2 bis 4. dadurch gekennzeichnet. dass der 
Kommunikationsrechnerknoten (5) als Zusatz-Baukomponente far den jeweiligen 
Prozessrechner1<noten (4) ausgeblldet ist. 

Netzwerk nach einem der AnsprQche 2 bis 5, dadurch gekennzeichnet, dass zum 
jeweiligen Datenaustausch jedem Kommunikationsmodul ein 
Prozessrechnerknoten (4) und/oder technisch- physlkalischer Prozess oder 
jedem Kommunikationsrechnerknoten (6) zumindest ein technisch-physikalischer 
Prozess oder ein Prozessrechneri<noten (4) zugeordnet ist. 

Netzwerk nach einem der AnsprQche 2 bis 5 oder nach Anspruch 7, dadurch 
gekennzeichnet, dass wenigstens einer der Kommunikationsrechnerknoten (5) 
mit mehreren ProzeBrechnerknoten vorzugsweise Qber ein. serielles 
Kommunikationssystem verbunden ist. 

Netzwerk nach einem der AnsprQche 2 bis 8, dadurch gekennzeichnet, dass das 
Kommunikationsmodul oder der Kommunikationsrechnerknoten (5) mit 
Funktionalitaten zur Fehlersuche oder Diagnose im Berelch wenigstens eines 
der ProzeBrechnerknoten und/oder technisch-physikalischen Prozesse versehen 
ist 

Netzwerk nach einem der vorangehenden AnsprQche, dadurch gekennzeichnet, 
dass der Diagnoserechnerknoten zur Bereitstellung oder UnterstOtzung 
webbasierter Bedienoberflachen insbesondere Qber DatenfernQbertragung Oder 
ein Weitverkehrsnetz ausgeblldet und mit den Bedienoberflachen entsprechende 
Funktionskomponenten versehen ist. 
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11. Netzwerk nach einem der vorangehenden AnsprQche, gekennzeichnet durch 
eine Strukturierung entsprechend der Client/Server-Architektur mit dem 
Diagnoserechnerknoten als Server. 

5 12. Diagnoserechnerknoten fOr ein Netzwerk nach Anspruch 11 und gegebenenfalls 
2, ausgebildet als Server mit Schnittstellen zu wenigstens einer Datenbank, zur 
Kommunikatlon mit den Kommunikations-. und/oder ProzeBrechnerknoten und 
sonstigen Client-Rechnerknoten. wobei die eine Oder mehreren Schnittstellen zu 
den sonstigen Client-Rechnerknoten mit einem Servlet-Container realisiert sind, 

10 welcher der Obertragung von Diagnosedaten, die aus den Schnittstellen zur 

Kommunikation mit den Kommunikations- und/oder ProzeBrechnerknoten 
erhaitlich sind, an die Clientknoten dient, und die eine oder mehreren 
Schnittstellen zu den Kommunikations- und/oder ProzeBrechnerknoten 
beziehungsweise Kommunikatinsmodulen auf der Basis des Ethernet realisiert 

15 sind. gekennzeichnet durch einen DIagnosekanal. der gebildet ist mit 

folgendem: 

mit einer Oder mehreren der den Kommunikations- und/oder 
Prozessrechnerknoten (4) zugeordneten Ethernet-Schnittstellen; 

mit einem Ereignis-Mangementmodul mit Datenbank-Zugriff. welches zur 
20 Verarbeitung der an den Ethernetschnittstellen erhaltenen Diagnosedaten 

ausgebildet ist; 

mit einem auf der Basis des Servlet-Containers angelegten Ereignis- 
Oberwachungsmodul, das Ausgangsdaten aus dem Ereignis-Managementmodul 
einem oder mehreren Applets auf externen Client-Rechnerknoten zur Verfugung 
25 stent. 

13. Diagnoserechnerknoten nach Anspruch 12, dadurch gekennzeichnet, dass dem 
Servlet-Container ein Webserver zur Generierung und Weiterubertragung von 
HTML-Seiten aus vom Servlet-Container erhaltenen Daten nachgeordnet ist. 

30 

14. Diagnoserechnerknoten nach Anspruch 12 oder 13. dadurch gekennzeichnet 
dass die Schnittstellen zur Kommunikatlon mit den Kommunikations- und/oder 
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Prozelirechnerknoten Qber XML-Protokolle, und/oder die Schnlttstellen zur 
Kommunikation mit den Client-Rechnerknoten Qber das SOAP (Simple Object 
Process Protocol) eingerichtet sind. 

15. Diagnoserechnerknoten nach einem der vorangehenden AnsprQche, 
gekennzelchnet durch ein programmtechnisch Oder softwaremaBIg derart 
eingerichtetes Kommunlkationsmodul, dass dadurch einer oder mehrere der 
Prozessrechnerknoten (4) an das Ethernet Oder sonstige Bus- 
Kommunikationssystem angebunden werden kann. 

16. Diagnoserechnerknoten nach einem der vorangehenden AnsprQche, 
gekennzelchnet durch ein Aniagen-Managementmodul mit Infonnationsdaten 
Qber die Konfiguration der technisch-physlkalischen Prozesse nebst zugehOrigen 
Prozessrechnerknoten (4) und einer oder mehrerer Funktionskomponenten, die 
zur Visualisierung der Konfiguration in Verbindung mit den Client-Rechnerknoten 
und/oder zum Bereithalten der Infomnationsdaten fQr weitere 
Datenverarbeitungsprozesse ausgebildet sind. 

17. Kommunikationsrechnerknoten (5) oder Kommunlkationsmodul ais Software- 
und/oder Fimiwaremodul, jeweils fOr das Netzwerk nach einem der AnsprQche 1 
bis 11, gekennzelchnet durch eine erste, dem wenigstens einen 
Diagnoserechnerknoten zugeordnete Schnittstelle, welche zur Kommunikation 
uber Protokolle der TGP/IP-Familie, einschlieBlich UDP/IP, vorzugsweise auf der 
Basis des Ethernet programmiert ist, und durch eine oder mehrere zweite, einem 
Oder mehreren der Prozessrechnerknoten (4) zugeordnete Schnittstellen, wobei 
die erste und die eine oder mehreren zweiten Schnittstellen miteinander 
koppelbar sind Qber einen oder mehrere Informationsbroker. die jeweils 
programm- und/oder schaltungstechnisch als Submodule zur bidirektlonalen, 
anfrage- und/oder ereignisbasierten Datenkommunikation zwischen erster und 
zweiter(n) Schnittstelle(n) ausgebildet sind. 
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18. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach Anspruch 
17. dadurch gekennzeichnet, dass die erste Schnittstelle zur Kommunikation auf 
der Basis von XML-Protokollen ausgebildet ist. 

19. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach Anspmch 
17 Oder 18, dadurch gekennzeichnet. dass die zweite Schnittstelle zur 
Verbindung mit einem seriellen Kommunikationssystem ausgebildet ist. 

20. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, dadurch gekennzeichnet, dass der eine oder die 
mehreren Infomnationsbroker eine oder mehrere Funktionskomponenten 
umfassen, die zur Fehlersuche oder Diagnose im Bereich der 
ProzeHrechnerknoten und/oder technisch-physikalischen Prozesse ausgebildet 
sind. 

21. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprUche, dadurch gekennzeichnet, dass mehrere 
Informationsbroker mit zueinander unterschiedlichen Funktionalitaten 
eingerichtet und mit einem Connection-Manager verbunden sind. der programm- 
und/oder schaltungstechnisch als Submodul zur Realisierung vorspezifizierter 
Prioritatsstufen ausgebildet ist, gemSB welcher mit der oder den zweiten 
Schnittstellen jeweils ein bestimmter der mehreren Informationsbroker 
verbindbar ist die jeweils eine Kommunikationsanforderung an den oder die 
Prozessrechnerknoten (4) aufweisen. 

22. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch einen Software- 
Informationsbroker zur bidirektionalen Obertragung von Firmware Oder sonstigen 
Daten oder kompletten Datensatzen von der ersten zu der oder den zweiten 
Schnittstellen. 
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23. Kommunikationsrechnerknoten (5) Oder Kommunikationsmodul nach Anspruch 
22, dadurch gekennzeichnet, dass zwischen dem Software-lnformationsbroker 
und der ersten Schnittstelle ein FTP (File Transfer Protocol) - Server 
zwischengeschaltet ist. 

5 

24. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch die Austattung mit einem 
nichtflochtigen Schreib-ZLesespeicher. insbesondere Flash-Speicher, mit 
welchem einer oder mehrere der Infomnationsbroker in Verbindung steht 

10 

25. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche. gekennzeichnet durch einen Parameter- 
Informationsbroker zur Realisierung einer vorzugsweise XML-basierten 
Schnittstelle fiir Lesen und/oder Schreiben von Parametem in einem oder 

15 mehreren zugeordneten Prozessrechnerknoten (4). 

26. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche. gekennzeichnet durch einen Fehler/Ereignis- 
Informationsbroker, der zur Kommunikation mit einem XML-basierten Protokoll 

20 auf der Basis von TCP/IP uber die erste Schnittstelle ausgebildet und mit einem 

von extern derart konfigurierbaren PrQf- und Triggerwerk versehen ist, dass bei 
Eintritt eines vorspezifizierten Ereignisses, beispielsweise Oberschreitens eines 
Toleranzlimits. im Bereich des oder der Prozessrechnerknoten (4) und/oder 
technisch-physikalischen Prozesses selbsttatig eine korespondierende 

25 NachrichtenQbermittlung zur e rsten Schnittstelle ausg elOst wird. 



27. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch die Einrichtung eines 
Interpreters fUr die Ablauffahigkeit von Skripten, die zum Zugriff auf 
Funktionselemente und/oder Informationsdaten in dem oder den 
Infomriationsbrokem zwecks AusfOhrung von Oberwachungs- und 
Diagnosefunktionen ausgebildet sind. 
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28. Kommunikatlonsrechnerknoten (5) oder Kommunikationsmodul nach Anspruch 
27, dadurch gekennzeichnet. dass der Interpreter mit einem mit der ersten 
Schnittstelle verbundenen FTP (File Transfer Protocol) - Server derart koppelbar 
1st, dass Ober die erste Schnittstelle empfangene Skripte ausfQhrbar sind. 

29. Kommunikatlonsrechnerknoten (5) nach einem der vorangehenden Anspruche, 
gekennzeichnet durch eine Ausbildung als Zusatzbaukomponente fQr einen 
jeweillgen Prozessrechnerknoten (4) und/oder eine bauliche Integration mit 
einem ProzeBrechnerknoten. 

30. Kommunikationsmodul nach einem der vorangehenden Ansproche, 
gekennzeichnet durch eine zumindest tellweise ablauffahlge Implementierung 
auf der Hard\A/are eines Prozess- und/oder DIagnoserechnerknotens. 
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